-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic implementaton of Transition node #439
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #439 +/- ##
==========================================
+ Coverage 73.36% 73.53% +0.17%
==========================================
Files 192 194 +2
Lines 5530 5582 +52
==========================================
+ Hits 4057 4105 +48
- Misses 1473 1477 +4 ☔ View full report in Codecov by Sentry. |
I'm not sure why tests are failing, some Aqua related stuff? |
Great work! We appreciate all you are doing! Code works fine on my machine. So here's where I'm at in terms of a rough sketch of what I'm going for (if it's even possible): I would totally enjoy putting out an RxInfer tutorial or two via livestreams with the Institute if we could nail this down (as I see potential for expanding from there, e.g., hierarchical modeling and modifying the POMDP beyond the original scheme), as I see most of the requirements are already accomplished in your code examples. I think you will receive much more support from the ActInf community, and probably our Institute learners (where we are collectively reading and studying the Friston et. al textbook annually, i.e. newcomers to the Institute who program are learning about POMDPs first), were you to establish a tutorial on making this key model architecture and process. The end goal, ultimately, is to understand RxInfer well enough in terms of our own priors to where we can then surpass them and, say, build hierarchical, multimodal, and other kinds of interesting architectures made possible by RxInfer. Primary requirements:
So a sort of rough sketch, where I have commented out desired but unintegrated components, is as follows:
References to the general ActInf POMDP:
I'm happy to discuss this further, clarify, revise my expectations, delete this comment and discuss elsewhere, etc. etc. Best, |
Hi @apashea , thanks for trying out the new functionality! Actually, the functionality you describe is already available, but requires some additional knowledge (that I'm currently working on to disentangle :) ). First of all, the Now, as for the goal specification, it is important to notice that in
Now there's some additional things I have to explain:
I hope this clarifies the new functionality a bit |
Thank you, Wouter, for your help and advisement! Super helpful to see more clarity concisely. Noted on moving towards deprecating Apologies, I may be way off course here, but now I am attempting to:
Note I'm using these little [var] tags to keep track of these, as were I to teach others concisely, I would want to be able to specify "___ is the line(s) of code to be included if you want the model to learn parameter ___ ."
|
There are two very simple reasons why your inference does not converge.
|
Very pleased to see this. Thank you so much. I'm looking forward to use this as soon as I can. |
This allows a generic transition function for Categorical distributions, such as POMDPs. It allows model structures like this:
The interface is:
out ~ Transition(in, parameters, additional_interfaces...)
, so we can add all kinds of different interfaces to this transition node. Let's say we have a categorical "context" state which should influence the transition function. We can add this easily with the same interface and node:If anything is not clear LMK.